ci: use changesets for versioning and publishing #2182
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
andrii-bodnar
force-pushed
the
ci/add-changeset
branch
from
c1d563c to
6b07e1b
Compare
size-limit report 📦
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2182 +/- ##
==========================================
- Coverage 77.05% 76.38% -0.67%
==========================================
Files 84 87 +3
Lines 2157 2439 +282
Branches 555 637 +82
==========================================
+ Hits 1662 1863 +201
- Misses 382 460 +78
- Partials 113 116 +3 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Interesting how flow with changesets should look like where next merged into main.
Also thinking about implementing a "true", CD approach, when everything what merged to main automatically published on a "canary" channel. Like nextjs and similar projects doing.
I believe that next branch in general is not needed. We should use main as a trunk, and create branches for version to have an ability for hotfixes.
| { | ||
| "$schema": "https://unpkg.com/@changesets/[email protected]/schema.json", | ||
| "changelog": ["@changesets/changelog-github", { "repo": "lingui/js-lingui" }], | ||
| "commit": false, | ||
| "fixed": [["@lingui/*"]], | ||
| "linked": [], | ||
| "ignore": [ | ||
| "*", | ||
| "@lingui/remote-loader" | ||
| ], | ||
| "access": "public", | ||
| "baseBranch": "main", | ||
| "updateInternalDependencies": "patch", | ||
| "___experimentalUnsafeOptions_WILL_CHANGE_IN_PATCH": { | ||
| "onlyUpdatePeerDependentsWhenOutOfRange": true, | ||
| "updateInternalDependents": "always" | ||
| } | ||
| } |
There was a problem hiding this comment.
There should be "private: false" to not public private packages (jest-mocks for example)
There was a problem hiding this comment.
There is no such option in the configuration (schema.json), changesets should ignore private packages by default
There was a problem hiding this comment.
| @@ -1,7 +1,7 @@ | |||
| { | |||
| "private": true, | |||
| "name": "@lingui/jest-mocks", | |||
| "version": "3.0.3", | |||
| "version": "5.1.2", | |||
There was a problem hiding this comment.
i think this package version here could be reset to "0.0.0" to avoid confusion with public packages
There was a problem hiding this comment.
This one is updated by changesets (as well as its CHANGELOG) because it's listed in the devDependencies of some packages and cannot be ignored even if it is private. Yes, it's strange and unexpected.
It's a known issue mentioned here - changesets/changesets#1158
There was a problem hiding this comment.
It could be ignored, i'm using changeset on my full-time job and we have plenty of the private packages and they don't get bumped
There was a problem hiding this comment.
Probably need some explanation here, you can tell changeset to ignore private packages in two ways:
- Remove the version field from package json. - This is a recomended way by theirs maintainers and it was there since the begining. Changeset will not bump packages which doesn't have a version field. However, this doesn't play well with a "workspace:" protocol in yarn / pnpm. They will fail publishing a package if encounter a link to a package without version field.
privatePackages: falsethis will disable changeset bump for packages with"private": true
|
As for canary releases, I think it's overcomplicated for the Lingui case. The flow with
Good question. Probably this could cause problems and the first stable release of the new major version should be done manually to make sure everything is ready for release. I am also still thinking about a separate workflow for publishing that should be triggered manually. This gives more control over the process. |
This is debatable, but I don’t think it’s complicated. In fact, it’s even simpler because it removes the need for branching entirely—it’s a shift in how we think about releases. The Instead, a more streamlined approach could be:
With this model, if a hotfix is needed for the latest stable version, you apply it there and cherry-pick it to This also benefits contributors, as they always work with the latest changes by default, without needing to be explicitly directed to a And as for canary releases, it's really just about automation—fresh changes are published automatically so contributors and early adopters can start using them right away. |
Description
This PR replaces Lerna with Changesets for package versioning and changelog.
Types of changes
Fixes #2127
Checklist